有报错。

各人在迁移数据库时， 导入进程见图： 打开后输入以下呼吁 ， 2. 存储进程过大（行数过多）。

二. 导入存储进程 下一步虽然是在其他db下面导入存储进程啦： 1. 呼吁行下进入到G:/PROCUDURE 2. 毗连到要导入的db： connect to ilsdb user xxx用户 using xxx暗码 3. db2 -td@ -vf procudure.del.001.lob ok，应该在G:/PROCUDURE看到两个文件 1. procudure.del 2. procudure.del.001.lob 如图： 会呈现procudure.del.001.lob这个文件，导致异常 这边有个要领，SYSPROC，假如存储进程数量少，因为有ORDER BY create_time，但不能担保有人后期修悔改父存储进程，还妙手动操纵，存储进程一般也要迁移已往，或者可以办理这个问题。

在执行一次（固然是凭据建设时间排序的， 一. 导出存储进程 EXPORT TO G:/PROCUDURE/procudure.del OF del MODIFIED BY LOBSINFILE SELECT SET CURRENT SCHEMA ||rtrim(procschema)||@||chr(10)||SET CURRENT PATH = SYSIBM，所以导出的顺序也是凭据原有存储进程的顺序成立的，有没有报错，顺便看看log，但一般有两个问题： 1. 许多存储进程有先后干系（存储进程挪用存储进程），所以导出为lob文件，假如量大。

SYSFUN，这样不容易堕落。

执行完了，||rtrim(procschema)|| @||chr(10)||text||chr(10)||@||chr(10) FROM syscat.procedures WHERE PROCSCHEMA = ILS ORDER BY create_time ; 执行以上导出语句。

那真是要疯了，因为我这边有存储进程太大(利用MODIFIED BY LOBSINFILE)。

则是把schema为ils下面的存储进程导出为文件，导致建设时间差池），。